Trusts abuses
Table of content
Domain trusts
Two domains can establish trust relations. This relation allows a user from domaine A
to access resources hosted in domain B
.
The trusts
relations can be :
- One way
- Two way
- Transitive
- Un-transitive
One way trust
A One way trust
is established from domain A
to domain B
. In this case, users from domain B
can access resources based in domain A
as domain A
TRUST domain B
.
However, users from domain A
cannot access resources based in domain B
.
Two way
In this kind of trust, the domains trust each other. Thus, users from domain A
can access resources based in domain B
and the other way around.
Transitive
Transitive relation imply that if domain A
trust domain B
and domain C
trust domain A
, then domain C
also trust domain B
. With this configuration, users from domain B
can access ressources inside domain C
without an domain C
explicitly trusting domain B
.
Parent and Child
By default, when a child domain is created, a bidirectional trust between the parent and the child is created.
Thus, if the child domain is compromised and a Domain Admin
account is retrieve, it is possible to compromise the parent domain too using the Domain Admin
TGT
with a SID History
attribute. Indeed, jump from on domain to another is only allowed to Entreprise Admin
users. Explicitly adding the user to the group is not needed, siimply adding the group SID
to the SID History
is enough.
There are several methods to add the Entreprise Admin
SID
into the user SID History
such as patching the NTDS
or through the DC Shadow
technique but the easiest way is to forge the TGT
with an extra SID
. Rubeus
support the /sids
parameter that can be used to request a ticket with extra SID
.
Golden
andDiamonds
tickets can be created withRubeus
using the/sids
parameter that will contains theEntreprise Admin
groupSID
.
Get TGT to another domain
First, an inter-realm
key is needed. Thus, the generation of the TGS
must be performed in three steps.
1 - Get TGT for the user
Rubeus.exe asktgt /user:${user} /domain:${startDomain} /aes256:${userKerberosKey} /nowrap
2 - Get a referal ticket
Ask a TGS
signed with the trust account NTLM.
Rubeus.exe asktgs /service:krbtgt/${targetDomain} /domain:${startDomain} /dc:${dcStartDomain} /ticket:${userTGTFromStep1} /nowrap
3 - Get TGS in the target domain
The
serverFromTagerDomain
and thetargetDomain
MUST be different servers !Rubeus.exe asktgs /service:cifs/${serverFromTargetDomain} /domain:${targetDomain} /dc:${dcFromTargetDomain} /ticket:${ticketFromStep2} /nowrap
Shared Trust Password
This technique can be used when there is a one-way trust where Domain A
trusts Domain B
and Domain A
has been compromised.
As the trust is a one-way trust, Domain A
should not be able to access ressources from Domain B
.
Both domains involved in a trust store a shared password that is renewed every 30 days in the Trust Domain Object
(TDO
). These objects can be read by LDAP
.
# AD Filter
(objectCategory=trustedDomain)
Likewise, there is a user created with the pattern DOMAINB$
. Once the key material is retrieved, it is possible to impersonnate this account to access to the trusted domain.
Dump from DC memory
The shared key material can be obtained directly by dumping the DC
memory. Once connected on the DC
mimikatz
can be used to extract the key material:
mimikatz lsadump::trust /patch
As we are patching the
DC
memory, this operation can be particularly risky
DCSync with the TDO GUID
First, get the TDO GUID
using PowerView
or ADExplorer
. Then, you can DCSync
:
mimikatz @lsadump::dcsync /domain:${domainA} /guid:{${TdoGuid}}
# Look at the `OUT` result only
Retrieve a TGT for Domain B
Rubeus.exe asktgt /user:${DomainB$} /domain:${DomainB} /rc4:${DomainBKey} /nowrap